SYSTEM FOR WIRELESS PUSH AND PULL 
BASED SERVICES 



Background of the Invention 

1 . Technical Field 

The invention relates to a proxy gateway for providing improved push and pull 
based services from a content provider on the Internet to a mobile user on a wireless 
network. 

2. Description of Related Art 

The Internet is a global network formed by the cooperative interconnection of 
computing networks. The Worldwide Web (WWW or Web) is a collection of files or 
"Web pages" of text, graphics and other media which are connected by hyperlinks to 
other Web pages which physically reside on the Internet. In a transaction on the WWW, 
a Web client typically requests information from a Web server. The requested 
information is transmitted from the Web server to the Web client over the Internet. 
Dramatically increasing expansion of Internet services using the WWW has led to 
increased Web traffic. 

A conventional technique to reduce Web traffic and speed up Web access is to 
store copies of documents in a cache. U.S. Patent No. 5,873,100 describes an Internet 
browser which includes an embedded cache for user controlled document retention. The 
cache stores a plurality of documents. At least one of the documents stored in thejcache 
is designated as a keep document. If the storage limit of the cache is exceeded, th&feache 
deletes the oldest document not designated as a keep document. ^ 

Web servers and Web client use hypertext transfer protocol (HTTP) / 1.1 which 
includes cache control features. See R. Fielding et al., "Hypertext Transport Protocol 
HTTP / 1.1" Network Working Group RFC, May 1996, URL: ftp://ftp.isi.edu/in- 
notes/rfc2068.txt. The original Web server assigns expiration times to responses 
generated for Web client requests. An expiration judgment is performed in the cache 
when a cached entry is requested by a client. If the cached entry has not expired, the 
cache sends the entry to the client; otherwise, it sends a conditional request to the Web 
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server. A validation check is performed at the Web server to validate if the cached entry 
is still useable. If the cached entry is useable, the Web server sends a validator to the 
Web client; otherwise, it sends an updated response. 

In certain systems, there exists very little local memory. In these systems, 
5 caching and prefetching is preferably performed at a proxy server intermediate between 
the Web server and the Web client. Prefetching is a technique in which additional items 
are fetched when a request is made for a particular item. U.S. Patent No. 5,925,100 
describes a system having a dumb client environment in which a smart server determines 
when to send a prefetched object to the user. The prefetched objects are determined 
10 based on an object based prefetch primitive present in the client's executing application. 

Other conventional prefetch schemes are based on predicting at a given time the 
likelihood that a given document will be accessed in the near future. Prefetch schemes 
y have been described in which a prediction module computes the access probability that a 

In file will be requested in the near future. Each file whose access probability exceeds a 

Cl 15 server's prefetch threshold is prefetched. See Z. Jiang and L. Kleinrock, "An Adaptive 
>j Network Prefetch Scheme," IEEE J. on Selec. Areas in Common., vol. 16, no. 3, April 

{p 1998, pp. 358-368, and Z. Jiang and L. Kleinrock, "Web Prefetching in a Client 

L Environment," IEEE Personal Communications, vol. 5, no. 5, Oct. 1998, pp. 25-34. 

ffl In addition, prefetch schemes have been described which are based on popularity 

hj 20 based prefetching. See E. P. Markatos, "Main Memory Caching of Web Documents," 
2 Computer Networks and ISDN Systems, vol. 28, issues 7-1 1, pp. 893-906, 1996. Main 

menu caching of frequently requested documents is performed on the Web server. 
Similarly, U.S. Patent No. 5,991,306 describes a pull based intelligent caching system for 
delivering data over the Internet. Content of frequently requested documents is 
25 downloaded from the content provider and cached at a local service provider. The 

content is cached prior to a peak time when subscribers are likely to request the content. 
A pattern recognizer detects behavior patterns based on subscriber requests to determine 
which content the subscribers are most likely to request and when. When content is 
finally requested, the data is streamed continuously for rendering at the subscriber 
30 computer. 
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Another prefetching scheme type is based on interactive prefetching in which 
prefetching is determined by the interaction between the client and the server. For 
example, an interactive prefetching scheme has been proposed in which the system 
gathers references by passing hypertext markup language (HTML) in the referenced page 
5 and collecting referenced pages with each request. See K. Chinen and S. Yamaguchi, 
"An Interactive Prefetching Proxy Server for Improvement of WWW Latency, " 
INET'97, Kuala Lumpur, Malaysia, 1997. 

Wireless systems and mobile users are typically limited to small bandwidth and 
small memory. A wireless application protocol (WAP) has been developed to promote 
10 industry-wide specifications for technology useful in developing applications and 

services, such as Internet services, that operate over wireless communication networks, as 
described in Wireless Architecture Protocol Specification, Wireless Application Protocol 
Q Forum, Ltd., Version 30, April 1998 and WAP Push Architectural Overview, Version 08, 

J November 1999. WAP framework defines pull technology as a transaction initiated by 

^ 15 the client to pull information from a server. For example, the World Wide Web is an 
SI example of pull technology in which a user enters a universal resource locator (URL) 

£ which is sent to the server and the server sends a Web page to the user. WAP framework 

L3 a 

=_ defines push technology as a transmission to the client without previous action by the 

O 

m client. Accordingly, the server pushes information to the client without an explicit 

Jf 20 request from the client. It is desirable to provide a system for wireless push and pull 

fU 

D based Internet services which expeditiously allows users to gain access to desired Web 

m information. 



Summary of the Invention 

25 The present invention relates to a method and system for providing Web content 

from pull and push based services running on Web content providers to mobile users. A 
proxy gateway connects the mobile users to the Web content providers. A prefetching 
module is used at the proxy gateway to optimize performance of the pull services by 
reducing average access latency. The prefetch module prioritizes pull content to be 

30 stored in a cache at the proxy gateway. The average access latency can be reduced by 
using at least one factor related to the frequency of access to the pull content, the update 
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cycle of the pull content determined by the Web content providers and the response delay 
for fetching pull content from the content provider to the proxy gateway. Pull content, 
such as documents, having the greatest average access latency are sorted and a 
predetermined number of the documents are prefetched into thexache. Push services are 

5 optimized by iteratively estimating a state of each of the mobile users to determine 

relevant push content to be forward to the mobile user. The estimate of the state of each 
mobile user can be determined from tracking information of the mobile user and geo- 
location measurement and behavior observation data. 

The invention will be more fully described by reference to the following 

10 drawings. 

Brief Description of the Drawings 
D Fig. 1 is a schematic diagram of a system for providing push and pull based 

U\ services to mobile users. 

rT 15 Fig. 2 is a flow diagram of an implementation of a prefetch module used in a 

SI proxy gateway of the system. 

=== 

m Fig. 3 is an illustration of a caching model. 

Fig. 4 is a schematic diagram for providing push services of the system, 
yi Fig. 5 is a flow diagram of an implementation of the mobile state prediction. 

m 20 

Q Detailed Description 

o 

Reference will now be made in greater detail to a preferred embodiment of the 
invention, an example of which is illustrated in the accompanying drawings. Wherever 
possible, the same reference numerals will be used throughout the drawings and the 
25 description to refer to the same or like parts. 

Fig. 1 illustrates a schematic diagram of a system for providing push and pull 
based services to mobile users 10. Mobile users 12a-12n are connected by mobile 
network 1 1 to proxy gateway 13. For example, mobile network 1 1 is a wireless network. 
Web server 14 is connected by network 15 to proxy gateway 13. For example, network 
30 15 can be a wired network, such as the Internet. 
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Each of mobile users 12a-12n can interact with pull service 16 and push service 
20 running on content provider 14, such as a Web server. As an example of pull service 
16, mobile user 12a generates a pull request 17 which is transmitted over network 1 1 to 
gateway 13. Pull request 17 is transmitted via proxy gateway 13 to pull service 16. 

5 Mobile user 12a receives pull response 18 generated by pull service 16 at content 

provider 14 via proxy gateway 13. Pull response 18 includes pull content 19 stored or 
generated by content provider 14. As an example of push service 20, push message 21 is 
sent by push service 20 to mobile user 12b. Push message 21 includes push content 22 
stored or generated at content provider 14. Push message 21 is sent by content provider 

10 14 to proxy gateway 13. Push message 21 is forwarded by proxy gateway 13 to mobile 
user 12b. 

Pull service 16 and push service 20 interact with cache 23, as described below. 
Pull response 18 generated by content provider 14 can be prefetched and cached in cache 
23. Thereafter, when pull request 17 identifies a pull response 18 stored in cache 23, pull 

15 response 18 stored in cache 23 can be forwarded to mobile user 12a, or any other mobile 
user 12b-12n, without contacting content provider 14. Prefetch module 24 reduces access 
latency of pull service 16 using document access log data 25 to determine prefetch 
control information 26 for prefetching a predetermined number of pull responses 18 into 
cache 23. Unprefetched pull response 18 is cached by using a conventional caching 

20 mechanism, such as HTTP/1. 1 caching. Mobile state estimation pedication module 27 
uses mobile tracking data 28 and geo-location measurement and behavior observation 
data 29 to determine push control information 30a for controlling caching of push 
messages 21 in cache 23 and for determining timing for sending relevant push content to 
the mobile user 30b depending on the state of mobile user 12b. It will be appreciated that 

25 multiple pull services 16 and push services 20 can be provided at content provider 14 or a 
plurality of content providers 14 and accessed by multiple mobile users 12a-12n. Pull 
content 19 and push content 22 can comprise, for example, documents including 
Hypertext Markup Language (HTML) files, Java files, and embedded data including 
images, video files and audio files. 

30 Fig. 2 illustrates a flow diagram for performing prefetch module 24. Prefetch 

module 24 optimizes performance of pull service 16 by reducing average access latency 
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using at least one factor related to the frequency of access to pull content 19, the update 
cycle of pull content 19, and the response delay for fetching pull content 19 from Web 
server 14 to cache 23. Access latency is defined as the time between when pull request 
17 is transmitted from a mobile user 12a-12n to the time when pull response 18 is 
5 received at a mobile user 12a-12n. Web server 14 generates content header 31 which is 
forwarded as a header of pull response 18. For example, content header 31 can include 
fields as defined in HTTP/1.1 such as: Expires time, relating to the expiration time of pull 
content 19; Last-Modified time, relating to the time pull content 19 was last modified at 
Web server 14; and Content-Length, relating to the size of pull content 19. Proxy 
10 gateway 13 receives content header 3 1 and stores fields of content header 3 1 in document 
access log data 25. Proxy gateway 13 also receives pull request 17 and stores fields 
related to pull request 17. Fields related to cache 23 are also stored in document access 
□ log data 25. For example, fields stored in document access log data 25 can include fields 

fS such as: request time, related to the local time when proxy gateway 13 made pull request 

15 17 to content provider 14; and responsetime, related to the local time when cache 23 
M received pull response 18 from content provider 14. 

E In block 32, variables related to pull service 16 are extracted from document 

Li = 

* access log data 25. For example, the extraction block 35 can calculate the parameters 

m associated with potential candidates that may be included into the list of the prefetched 

IT 20 documents. The document that has only one access record (i.e., no revisit) in the log or 
O has not more than one update cycle during the statistic period is not treated as a potential 

w candidate. Let R„ be the average rate of access to pull content 19. Pull content 19 is 

referred to as document n. R„ can be determined at proxy gateway 13 based on log data 
of cache 23 and content header 3 1 of pull responses 18 from content providers 14 and 
25 stored in document access log data 25. Let % be the size of document n. For example, Sn 
can be determined from the Content-Length field forwarded by content provider 14 and 
stored in document access log data 25. 

Let AT n be the average response delay imposed by network 15 which can be 
measured by the time from when pull request 17 from a mobile user 12a-12n is 
30 reformatted and forwarded by proxy gateway 13 to content provider 14 to when pull 

content 19 is fetched from or validated by content provider 14 to cache 23, i.e. which can 
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be measured by the difference between the logged requestjime and response_time. 
is the average time delay imposed by network 1 1 and network 15, which is the time from 
when, pull request 17 is generated from mobile user 12a where pull request 17 is 
reformatted and is forwarded by proxy gateway 13 to content provider 14 and pull 
5 content 19 is fetched from or validated by content provider 14 as pull response 18 to 

proxy gateway 13 to when response 18 is received by mobile user 12a. T c ^ is the average 
time delay imposed by network 1 1, which is the time between the generation of pull 
request 17 from mobile user 12a and the reception of pull response 18 by mobile user 12a 
when a valid copy of pull content 19, document n, is found in cache 23, including 
10 transmission time of pull response 18, roundtrip time from cache 23 to mobile user 12a 
and cache 23 processing time. Approximately, AT n = Ts, n - T c>n . Let |in be the update 
cycle of pull content 19, document n, which is the average length of time between two 

4f successive expiration times or two successive modifications of pull content 19, document 

m n. 

15 The caching model of HTTP/1 . 1 is illustrated in Fig. 3 in which tk represents the 

Last_Modified time and "°" represents the Expires time of pull content 19, document n 
m generated by Web server 14. Cache 23 is accessed by a group of mobile users 12a-12n 

L. and N is the total number of documents n residing in various Web servers 14 with n = 1, 

yi . . . N. Pull request 17a generated by one of mobile users 12a-12n and forwarded to cache 

ry 20 23 in cycle, |i n , cannot be satisfied by cache 23 which is denoted by missing 1. Cache 23 
t? fetches a copy of pull content 19 for pull request 17a from Web server 14. Consequent 

pull requests 17b and 17c generated by one of mobile users 12a-12n in cycle, fin, are 
satisfied by cache 23 which is denoted by hit 1 and hit 2. Thereafter, in a second cycle, 
Hn, pull request 17d generated by one of mobile users 12a-12n and forwarded to cache 23 
25 in cycle, ^, cannot be satisfied by cache 23 which is denoted by missing 2. Cache 23 
fetches a fresh copy of pull content 19 for pull request 17d from Web server 14. 
Consequent pull requests 17e-g generated by one of mobile users 12a-12n in cycle, (!„, 
are satisfied by cache 23 which are denoted respectively by hits 3-5. In a third cycle, |i„, 
pull request 17h generated by one of mobile users 12a-12n and forwarded to cache 23 in 
30 cycle, (in, cannot be satisfied by cache 23 which is denoted by missing 3. Thereafter, pull 
request 17i generated by one of mobile users 12a-12n arrives at cache 23 between the 
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expiration time and end of cycle, |i n . In this case, cache 23 validates pull content 19 at 
Web server 14, represented by validate 1, before using pull content 19 stored in cache 23. 
The distribution of interarrival time of pull requests 17a-17i to pull content 19 
represented by document n is represented by f n (t) which can be an exponential 
5 distribution. Since Web server 14 typically specifies the expires time based on its 

schedule to the end of cycle, |a n , the interval between the Expires time and the end of the 
cycle can have a stochastic or deterministic distribution. 

In block 34 of Fig. 2, the access probability of access to document n, represented 
by y n is determined by: 
10 y n = R„/R (1) 

wherein R is the total rate of access traffic on network 15 from gateway 13, which 
is the sum of Rn for n=l, 2, N. 

In block 36, the average hit rate for document n, represented by h„, is determined 

by: 

15 h " =1 -7^> n=l,2, ...,N, (2) 



in which: 

gn is the probability that there is at least one request to document n during a given 
Qi update cycle, n n , given by: 

g g»= I n=l,2,...,N, (3) 

□ 20 and 

Rn|in is the expected number of accesses to document n in an update cycle of 
document n. 

In block 38, the wired network access latency, represented by t^, imposed by 
25 network 15 when the request is the first one for document n in the update cycle /i n or 
Expires time for document n has been exceeded, as shown in Fig. 3, is computed from: 
iln = Yn(l-hn) AT„, n = 1, ...,N, (4) 
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The values at r\ n , n = 1, . . N are sorted in descending order with document 1 having the 
greatest average latency imposed by network 15 labeled as r\\, and document N having 
the least average latency labeled as r|N and relabeled as: Tii > r| 2 > r|3 > . . . > t|n. 

5 In block 40, the total number of documents n to be prefetched to cache 23, 

represented by r, is determined by considering at least one factor. Examples of factors 
include: spare capacity of cache 23 that can be utilized by the prefetching after providing 
sufficient capacity for conventional caching, AC; spare transmission bandwidth, AB, of 
network 15; and desired improvement of hit probability, AH. The total number of 

10 documents to be prefetched represented by r satisfies all of the following constraints: 
The constraint of spare cache capacity, AC, is given by 

2 s„(l-h n )<AC; (5) 

N N 

where AC » C - ^s n h n , C is given capacity of cache 23 and ^s n h n is the capacity 

n=l n=l 

required for conventional caching such as described in the caching model of HTTP/1.1. 
15 The constraint of spare transmission bandwidth, AB, on network 15 is given by: 



£ jfc < AB; (6) 



n=\ 



N s N 



where AB « B - ^ g n — , B is given bandwidth and ^ g n is the bandwidth required 
for conventional caching. 

The constraint of desired minimum improvement of hit probability, AH, is given by: 
20 2>(l-hn)>AH (7) 

n=l 

where AH » H - ^J/fh n , H is given hit probability, and ^ ph n is the total average hit 

probability for conventional caching. 

In block 41, the total number of documents to be prefetched to cache 23, r, that 
correspond to the r largest are selected and relabeled as r\u • . ^r. In block 42, the 
25 documents determined in block 41 are prefetched into cache 23 at proxy gateway 13 as 
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soon as the documents expire at cache 23, which means the prefetched document n in 
cache 23 is updated with average cycle, |i n , as shown in block 43. Thereafter, blocks 32- 
43 are repeated with a given period, such as several hours, several days, or several times 
the expected update cycle, fi , is represented by: 

5 M = tr n M n (8') 

Accordingly, average latency for pull service 16 is derived as: 

L = 2> n [hnT c , n + (l-hJTJ - J> a (8) 

n-1 n-1 

In Eq. (8), the first term is the latency of a conventional cache scheme and is independent 

r 

10 of the prefetch scheme used and the second term ^ 77 n is the latency reduction as a result 

n-1 

of prefetch scheme of the present invention. The latency reduction is determined by the 
number r and the selection of r prefetched documents. Thus, performance of blocks 32- 
43 minimizes the average latency L. 

Fig. 4 illustrates a schematic diagram for providing push services of the system. 
15 Movement and behavior of the mobile user 50 is measured by geo-location measurement 
and behavior observation block 29. An example of movement and behavior of the 
mobile user data 50 is represented in Table 1 illustrating examples of different states a 
mobile user 12a-12n can occupy. 

20 Table 1 Mobile States 



State 


Description 


Position 

and 
Behavior 


Time 


Speed 


Direction 


Mean dwell 
time in the 
state 


State 0 


Inactive (power off or 
out off location- 
dependent services). 










do 


State 1 


Walking on a street 


X, 


ti 


«lm/s 


along one 
direction 


di 


State 2 


In a shopping mall. 


x 2 


open hours 






d 2 


State 3 


Drive on a highway. 


x 3 


t 3 


«30m/s 


along one 
direction 


d 3 


1 


1 












State M-l 












dMH 
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5 



10 



: E 

15 



S 20 



25 



30 



State 0 is an inactive state in which mobile user 12a-12n can occupy when 
powering off its mobile terminal or is out of location-dependent services of wireless 
network 11. State 1 to State M-l are active states which mobile user 12a-12n can occupy 
while being actively involved with network 1 1 and interacting with pull service 16 and 
push service 20. Each state is determined by several parameters such as: position and 
behavior of mobile user 12a-12n, at time t represented by Xt, time of determining state, 
represented by t; speed of mobile user 12a-12n; direction of movement of mobile user 
12a-12n; and mean dwell time in state m, represented by d m wherein M is the total 
number of distinct states defined for mobile user 12a-12n, and m=0, 1, M-l. Y t 
represents the results of geo-location position measurement and behavior observations of 
mobile user 12a-12n at time t. It is observed that Y t is the observed or measured value of 
the position and behavior of mobile user 12a-12n and is in general different from Xt 
which is the true, but unknown, position and behavior because of geo-location and 
estimation error. Geo-location position and behavior data 29 can be estimated with 
conventional methods as described in J.H. Reed, K J. Krizman, B.D. Woerner and T.S. 
Rappaport, "An Overview of the Challenges and Progress in Meeting the E-91 1 
Requirement for Location Service", IEEE Communications Magazine, Vol. 36, No. 4, 
April 1998, pp. 30-37, hereby incorporated by reference into this application. 
S t is the state of mobile user 12a-12n at time t wherein S t e {0, 1, M-l}. 

Mobile user 12a-12n can transit from one state to another. The transit mobility of 
one of mobile users 12a-12n, mobile user 12, can be represented by an M-state Markov 
chain with transition probability matrix (TPM): 

P=[Pmn]MXM (9) 

where the pmn is the probability of transition from state m to state n, and m, n=0, 1, M- 
1. 

Tracking data 28 represents sequence data of mobile user 12 over time. Tracking data 28 
includes Yi* and {a T (m), t=1, t, m=l, m-l} 

S/ represents the state sequence of mobile user 12 from time 1 to t. Xy represents the 
corresponding position and behavior sequence of mobile user 12 from time 1 to t 
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Yi l represents the corresponding geo-location and observation sequence of mobile user 
12 from time 1 to t Mobile state prediction module 27 can generate push control in 
information 30 for controlling caching of push content 22 and for determining timing for 
sending push content 30b in cache 23 to mobile user 12 based on determined states. 



27. Mobile state prediction module 27 estimates the posteriori probability of the states of 
mobile user 12a-12n for a given geo-location and observation sequence, Yi\ 

In block 60, the initial state of mobile user 12a-12n is defined upon registration of 
mobile user 12a-12n in system 10. Let ctt(m) represent a forward variable for state 
10 sequence estimation which is a probability that the State at time t is m and the 
corresponding geo-location and observation sequence is Yi\ 

The forward variables for state sequence estimation for mobile user 12 in the 
initial time are: 



behavior of mobile user 12, Y t , is determined for determining geo-location measurement 
and behavior observation data 29. 

In block 63, the probability Pr{ Y t | X} that the geo-location measured result is Y t 
when mobile user 12 position and behavior is X is predetermined by the geolocation and 
20 observation error distribution. 

In blocks 65 the values required for iteration are stored in a database which values 
can be mobile tracking data 28. In block 64, state sequence estimation variable ott(m) for 
all 111=1, 2 . . . M-l is determined, which is stored into the database for the next recursive 
computation. 

25 The following analysis can be used for performing block 64. At time t, tracking data 

is represented by: Yi l = (Yi, Y2, . . ., Y t -i, Y t ) where Y t is the current measured data of the 
position and the behavior of mobile user 12 from the geo-location measurement and the 
collected information of proxy gateway 13. ou(m) is computed for all m=l, 2, . . M-l, by 
iterations from 1 through t from the following: 



5 



Fig. 5 is a flow diagram of an implementation of mobile state prediction module 



15 



Oo(0)=l, ao(m)=0, for m=l, 2, M-l. 
In block 62, a measured or observed value of a current geo-location position and 



30 



(10) 



m'=0 
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= ]£Pr (St-i = m'; Yi 1 ' 1 } Pr {S t = m; Y t |S t -i = m'}, (1 1) 

m'-O 

= 2> M ( m '> Pm' m 2 Pr ( x I m}Pr{Y t | x} (12) 

wherein p m < m is the state transition probability of mobile user 12, Pr{ x | m} is the probability 
that the mobile user locates at position and behavior as x when it is in state m at time t, for 
example the output probability of the Markov source, and Pr{ Y t I x} is the probability that the 
geo-location measured result is Y t when the mobile's position and behavior is x at time t. 

In block 66, state z is determined by: 

z = arg max{Pr{St = m|Yi t }|m=l,2,...,M-l}, (13) 
in 

= argmax{^^P|m=l,2,...,M-l}, (14) 
"> Pr{Yi } 

= arg max {a t (m) |m = 1,2,...,M-1}. (15) 

m 

Accordingly, blocks 60, 63, 64 and 66 determine mobile state prediction module 27. 

In block 68, state z related push content 22 is pushed to mobile user 12a-12n as 
relevant push content to the mobile user 30b. In block 69, mobile user 12 may accept or reject 
push content 22 and this behavior is observed by block 62. The mobile user's current 
behavior and position is forwarded to block 62 and block 62-69 can be repeated. 

It is to be understood that the above-described embodiments are illustrative of 
only a few of the many possible specific embodiments which can represent applications 
of the principles of the invention. Numerous and varied other arrangements can be 
readily devised in accordance with these principles by those skilled in the art without 
departing from the spirit and scope of the invention. 
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